$webwork.htmlEncode($page.space.name) : 2. WFS
This page last changed on Dec 18, 2007 by aaime.

General introduction

A WFS allows uniform access to features stored on a server. Use a WFS when you want to perform actions such as:

  • query a dataset and retrieve the features
  • find the feature definition (feature's property names and types)
  • add features to dataset
  • delete feature from a dataset
  • update feature in a dataset
  • lock features to prevent modification
    Whats the difference between a WFS-T and a WFS

    A WFS-T ("WFS-Transactional") is a WFS that supports Transactions - add, delete, or update features.

    The Web Feature Service (WFS) is easily one of the most valuable specifications of the OGC. It provides a generic way to access raw geographic data over the web. To the general user, this can potentially provide a wealth of information embedded in the map being viewed. Parts of the WMS spec tried to implement this functionality, but using a WFS gives much more control over how to actually access that data. Complex Filters serve as the OWS equivalent of a SQL WHERE statement, allowing you to select all four lane roads that are longer than 2 kilometers that start with D, for example.

The other feature of interest to users is 'Transactions', being able to insert, update, and delete feature on a map. The GeoServer User Map is an example of this, where users can zoom and select 'Add User' on a certain point, and it will be inserted into the backend database. Locking allows additional control over transactions, so that users do not overwrite data others are modifying.

In short, WFS leads to greater transparency and openness in mapping applications. Instead of merely being able to look at a picture of the map, as the provider wants the user to see, the power is in the hands of the user to determine how to visualize the raw geographic and associated data. The data can be downloaded and given further analysis and combined with other data, or it can be chained with other web services to do even more interesting things on the web. The transactional capabilities open up the possibilities for collaborations across the internet. Users no longer need permissions to access the same spatial database, they can just use the standard WFS-T interface. This has the potential to truly enable open geo-data, just as the internet plus networked source code management tools enabled the open source movement.

For more information about WFS see the WFS 1.0 and WFS 1.1 specifications at OGC

WFS 1.0, WFS 1.1

At the time of writing there are two WFS specifications:

  • WFS 1.0, which is the most widely used at the time of writing
  • WFS 1.1, which is more recent and not as widespread

GeoServer up to version 1.5.x supports only WFS 1.0, starting from GeoServer 1.6.0 we do support WFS 1.1 too.
The major differences between the specifications are:

  • the default GML version returned is GML3, which has different ways of specifying a geometry (you can still
    ask for output format to be GML2 thought)
  • the way to specify the srs has gone from http://www.opengis.net/gml/srs/epsg.xml#XXXX to urn:x-ogc:def:crs:EPSG:XXXX and this has deep implications on the axis order or the returned data (see the next section for more details).
  • WFS 1.1 does support on the fly reprojection of data, so you can ask your data to be returned in a SRS other than the native one.

According to the specification, when you're hitting the capabilities request without specifying a version you'll get back the highest version supported byt the server. This means the WFS capabilities link now returns WFS 1.1 capabilities (whose structure is different than the 1.0 version).
A full blown client will know how to negotiate the version it can support, but lesser clients may have troubles. If you know your client cannot negotiate the version properly you can give it a capabilities link that specifies the version explicitly to circumvent the issue:

http://host:port/geoserver/wfs?request=GetCapabilities&service=WFS&version=1.0.0

The axis order issue

Most (if not all) WFS 1.0 servers available on the internet will return geographic coordinates in longitude/latitude order. It's the way most GIS systems work, and the most common way to distribute data as well (most, if not all, shapefiles available for download on the net adopt this order).

The trouble is, geographic and cartographic traditional order is the opposite: first latitude, then longitude.
The WFS 1.0 and WMS 1.1 specifications waren't clear about which axis order was supposed to be used, and as a result everybody adopted the one commonly used in GIS system. The WFS 1.0 ways to specify an EPSG code where http://www.opengis.net/gml/srs/epsg.xml#xxxx or EPSG:xxxx, nor syntax seemed to mandate a clear axis order.

The WFS 1.1 specification mandates the usage of the the urn:x-ogc:def:crs:EPSG:xxxx, which is specified as to something respecting "the authority axis order". In the case of the official EPSG database, that axis order is always latitude/longitude for geographic data. In order to be certified compliant with WFS 1.1 a server has to use that way of specifying an SRS name in the capabilities, making latitude/longitude the default axis order for all requests.

Long story short, if you are making a WFS 1.1 GetFeature request on a geographic data set you'll get back coordinates in latitude/longitude orders.
Yet, since the old ways of specifying the SRS were not as strict about axis order, and since the GIS community already provided an interpretation of them with their feet (and implementations) the GeoServer developers decided to use the following interpretations of SRS codes:

In this way depending on the client you'll be able to get data in whatever axis order you want. A fully compliant WFS 1.1 client will have to deal with latitude/longitude axis, whilst everything else might still be using the old ways of specifying an SRS name and receive back data in longitude/latitude order.

More information

You can get more information about WFS and GeoServer specific extensions here:
Document generated by Confluence on Jan 16, 2008 23:27